home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
rbbs_pc
/
rbbsdocs.zip
/
RBBSDOCS.12B
< prev
next >
Wrap
Text File
|
1990-11-05
|
27KB
|
528 lines
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-10
DKAAAA.ZIP is ready for download.
DKAAAAa.ZIP is ready for download.
DKAAAAb.ZIP is read for download.
As each file is downloaded successfully it is removed from the list and is
no longer displayed to the user as ready for download.
12.6.2 The "Library" Subsystem and PC-SIG's CD-ROM
--------------------------------------------------
The CD-ROM published by PC-SIG consists of a DOS subdirectory for each 360K
diskette in the PC-SIG library. Sometimes the disk contains all the files
already in the ARC format other times they just contain a group of files.
The key here is the A)rchive function. The resulting file to be made
available for download will NEVER be greater than 360k. This is important
since a caller may only have a floppy based system and could not capture a
file any larger than a 360k floppy can contain.
The PC-SIG's CD-ROM creates the problem of listing both the individual
files contained on each diskette as well as a summary description of the
individual disks. This can be solved by listing each of the 18,000+ files
in the MASTER.CDR using positions 43-76 for the description, positions 77-
79 for the disk drive, and positions 80-82 for the valid categories for
downloading. These are contained in the file specified by CONFIG parameter
217.
MASTER.CDR might also contain a list of names of the files that would be
created by the A)rchive function. This allows the caller to scan a
category (i.e. category 200) for disk titles only. Note that the files do
not exist until the user uses the A)rchive function. A SysOp who did not
wish to allow individual file downloads might only include these entries in
the MASTER.CDR rather than the other 18,000 entries.
The directory for the PC-SIG CD-ROM is over 1.5 megabytes in length and can
take up to 10 minutes to search completely (when using a PC at 4.77 MHz).
If the SysOp is using FMS, it is recommended that the category file for the
normal FMS directory and the category file for the Library FMS directory be
the same (PC-SIG has 27 different categories for its files).
12.7 Creating the Personal Files Directory
------------------------------------------
RBBS-PC's "personal" file support is analogous to RBBS-PC's support of
"personal" messages in that these files are specially addressed to a
specific caller or group of callers based on security. Personal file
downloads differ from the general download in three major ways:
1) the time limit check is bypassed in personal downloads, meaning that a
qualifying caller can download a file regardless of time left.
2) only files explicitly listed in the personal directory can be
downloaded. Normally files to be downloaded will be looked for on the
disk(s) where files are available for downloading whether they are
listed in a directory or not.
3) only callers with matching user record or sufficient security can
download a file. Normally any caller with security enough to issue
the download command can download a file.
RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-11
Personal files provide a way that files can be delivered to specific
individuals. As an example, a vendor's support bulletin board for a
software product might make the upgrade downloadable only by paying
customers. A credit reporting corporation can make credit reports
electronically available only to the people who order them. Or, a SysOp
can make a file privately available to only one caller.
One of the most useful applications for personal downloads is to make
certain files available regardless of time remaining. Previously, SysOps
had to increase the security of callers or set artificially high session
limits just to make certain large files available. By putting these file
names in the personal directory and limited by security level, these files
can be made available regardless of how little time is left. For example,
the large files comprising RBBS-PC can be made downloadable to all callers
even though they are limited to 30 minutes.
Access to personal files can be limited in two ways. First, the files can
be downloaded only by callers which have a matching value in their user
record. For example, files can be limited by name (any field in the user
record can be selected). Alternatively files can be limited by security
level, meaning that a file can be downloaded by any person with that
security level or higher. File access based on security level can also be
accomplished using the standard RBBS-PC file security mechanism, but to do
so places the caller's under the standard RBBS-PC constraints of maximum
time per session/day.
Using the "P)ersonal files" command in the files section, a caller is asked
what files the caller wants to download. The only files available to the
caller for downloading are those explicitly listed as belonging to the
caller, unlike the general download command which will look for any named
file on the disk. The caller can ask to List the files available. Callers
will see only those belonging to them.
There is a special option to download all and only the "new" files
specifically addressed to the user by matching a field in the caller's user
record. RBBS-PC keeps track of whether the caller has ever downloaded the
personal file. When listing, new personal files are marked with an "*" in
front of their names (they are "tagged"). Selecting the new files starts a
multi-file download for all and only the personal files the caller has
never successfully downloaded.
Files you want downloaded ONLY through the personal file features of
RBBS-PC should be put in their own subdirectory as specified in CONFIG
parameter 142. If you put the personal files in a download subdirectory
they would be available then to anyone who could name them. RBBS-PC will
search the download areas for a personal file if it is not found in the
subdirectory specified in parameter 142.
Second, in the same place as the personal files themselves, put in a
special personal directory with name specified in CONFIG parameter 143.
This directory is the same format as the general file directories of RBBS-
PC. The format is as follows:
Default Field
Positions Length Description of Field
1 - 12 12 The first 12 characters of an entry have the file name,
with no internal spaces.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-12
13 - 73 Variable The next group of characters can have anything in them.
This will be displayed to the caller who asks for a
listing, along with the file name in the first 12
columns. The length of this group is 21 characters
plus the length of the upload description specified in
CONFIG (40-46, defaults to 40). The default length of
this field is 61 characters.
74 -104 Variable The next group of characters are what is used to
identify the file as "belonging" to the caller and must
match a field in the user record. In CONFIG parameter
43 and parameter 44, the SysOp specifies the position
in the user record to use and how many characters. The
default is to begin in column 1 and use 31 characters
for the caller's name, but any field in the user record
can be used. Optionally, a security can be entered in
this last field to limit the file based on the security
level of the caller. To use security rather than a
match on the user record, simply put a blank as the
first character in the field, followed by the security
level.
105 1 The last character must be an "*" to signify that the
file has never been downloaded or an exclamation point
if ever downloaded.
This personal directory works very much like the File Management System
shared directory, using a field in the user record as the category and
limiting callers to their one category, or limiting the file to the group
of caller's with the minimum required security. The personal directory is
fixed length and read in reverse from bottom to top.
After setting up or modifying the personal directory, you use the CONFIG
utility parameter 187 to check whether the personal directory has the
proper format.
The personal directory can be created by a text editor (i.e. EDLIN) but be
sure to put in the "*" in the last column when creating a new entry so that
the file will be tagged as new. Also be sure to make each entry fixed
length. If the user's identity does not fill out the length of the last
field, be sure to pad the record with blanks out to the full length.
When setting up a personal file directory there are seven configuration
options peculiar to personal files:
CONFIG Description
parameter 43 what part of the user record used to identify files as
parameter 44 belonging to the user (beginning column and length),
parameter 143 the name of the personal directory,
parameter 142 the drive and path where the personal files and personal
directory are stored,
parameter 144 the protocol that must be used downloading,
parameter 147 whether the files downloaded are to be concatenated, and
parameter 188 the CONFIG utility to check the structure of the personal
directory to make sure it is in the properly format.
Parameter 147 and parameter 187 require some explanation of how they might
be used. Limiting the caller to a required protocol to use is not
something one would generally do. But, for special purpose downloads, like
RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-13
downloading to a printer, one might want to require ASCII, for example.
Or, if all callers are to use the same communications package or only a
particular protocol is efficient, you can specify what callers must use.
Concatenating files means that when multiple files are specified for
downloading, the files are sent continuously in one stream of data rather
than individually as separate files. In effect, the files are physically
combined at the time of downloading. All messages between files are
suppressed - the only messages that appear to the caller are those that
normally occur when the first file transfer starts and when the last file
transfer ends. Concatenation is currently supported only for ASCII
downloads.
An example of a situation that might use this feature of RBBS-PC is a
business that generates short reports for clients. Their clients want to
call in remotely to get time-critical reports and print them right in their
office on pre-formatted paper. Each report is a separate file on RBBS-PC
with all the necessary printer commands already included in each file.
A SysOp might set up RBBS-PC such that the main menu was restructured to
make the P)ersonal files function be P)rint reports to reflect the more
specialized nature of the board. Callers to this board would call in,
identify themselves, and select P)rint reports from the main menu. Callers
could use L)ist to see what is available if they are looking for some
report in particular; just select all new reports; or ask for a particular
report if they must have it immediately.
In the last two cases, RBBS-PC would notify the caller to set up to receive
and press [ENTER] when ready. The pre-formatted reports with embedded
printer control sequences would stream out onto the paper (including
formatting like bold or underline) positioning the text to fit in boxes.
The paper is automatically advanced as needed. When done, RBBS-PC beeps
the user, who then turns the "save to printer" feature off of whatever
communications package is being used.
To set up this application, the personal file options would be configured
to use the caller's id (e.g. account number). The files and directory
would be put in a special subdirectory not shared with anything else. The
CONFIG parameters would be set to specify that caller's must use ASCII
("A") as their protocol and that multi-file downloads will be concatenated.
Another example is that of an electronic job placement service that wanted
to limit non-subscribers to a security level 5 with 10 minutes. However,
they also want non-subscribes to be able to download a file of potential
employment opportunities that may take more than 10 minutes. The following
entries would be put into PRIV.DIR:
JOBSFORU.ARC 282888 07-14-87 List of job opportunities you might want 5
/|\ /|\
12 74
Each record is padded with blanks so that 29 blank characters follow the
security level, followed by an '*'. The '*' is not shown in this
documentation since it is in a column too far to the right.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-14
12.8 Automatically Checking & Converting Uploaded Files
-------------------------------------------------------
Verifying the Integrity of a File
---------------------------------
RBBS-PC's on-going commitment to providing SysOps with the ability to
protect themselves and their callers is reflected in precisely this kind of
feature. When a file is uploaded, RBBS-PC will look for a file called
T<ext>.BAT (where <ext> is the characters that make up the extension of the
uploaded file). RBBS-PC looks for this file on the drive and path
specified in CONFIG parameter 105. If this file exits, RBBS-PC will SHELL
to either:
a.) the program specified in the file (if it only has one line) or
b.) to the .BAT file itself.
In this way a SysOp may install whatever processing is desired after a file
has been uploaded.
If the BAT file contains exactly 1 line, RBBS-PC will shell to the contents
of the bat file, passing on the command line the two parameters:
a.) the name of the file upload (first) and
b.) the name of the file to write the results to (second)
If the BAT file contains more than one line, RBBS-PC will SHELL to the BAT
file itself, passing
a.) the name of the file upload for "[1]" and
b.) the name of the file to write the results to for "[2]"
as the first and second parameters, respectively.
RBBS-PC will consider the upload to have failed and delete the uploaded
file, if the file to which the results are to be written has a length
greater than 2 bytes. The BAT file should either
a.) not write a result file or
b.) leave an empty one if the upload is okay.
If the file that was uploaded is not okay, the external application should
write out some error message more than 2 bytes long.
A typical use for this feature of RBBS-PC is to test the compression of the
uploaded file and pipe the results to a text scanner that looks for an
error string and redirects the output to a file if an error is found. For
example if files that are uploaded with the extension .ZIP were to be
tested, a SysOp might create the file TZIP.BAT
PKUNZIP -T [1] | FGREP "error in a" > [2]
An alternative implementation is:
PKUNZIP -T %1
IF ERRORLEVEL 1 ECHO BAD UPLOAD > %2
SETERROR 0
Under versions of QuickBASIC prior to 4.5, programs that reset the error
level cause illegal function call 5 upon return from the SHELL. Therefore
RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-15
it is necessary to run a utility to reset the error level back to 0 before
going back to RBBS-PC. This is what the SETERROR.EXE file does.
The recommended procedure is to use PKUNZIP, check errorlevel, and reset
error level to 0. PKUNZIP outs somewhat variable strings when different
errors occur, making a filter based on text more difficult to implement.
Converting Uploads
------------------
RBBS-PC can be configured by the SysOp to cause uploads with extension <u-
ext> to be converted to the default extension <d-ext>. To do this, the
SysOp must put a file named C<u-ext><d-ext>.BAT on the drive and path
specified in CONFIG parameter 105. If the file exists, RBBS-PC will SHELL
to it.
If the SysOp wants all .ARC files uploaded converted to a .ZIP file, create
a file CARCZIP.BAT in the subdirectory specified in CONFIG parameter 105.
To convert .PAK files to .ZIP, create the file CPAKZIP.BAT. Sample
conversion batch files are included on the RBBS-PC distribution diskettes.
12.9 Fast File Search
---------------------
RBBS-PC 17.3 includes an enhanced file-search capability for uploads and
downloads. This enhancement has two advantages:
(a) File searches are much faster. In the case of very slow devices like
a CD-ROM, this can be the difference between sub-second response and
a 45 second response. File searches are now virtually instantaneous.
(b) Files not stored on this system can trigger macros. This allows
requests for files stored elsewhere, either off line on backups, or on
other cooperating systems, to trigger later processing.
The basis for the fast file search is a file, configuration parameter 267,
which is a sorted list of file names available for downloading. The
default name is FIDX.DEF.
The format of this file is:
columns 1-12: file name
columns 13-16: location index (1, 2, 3, ...)
columns 17-18: carriage return line feed.
All data is stored as character data and the file is editable. The file
names must be stored with no internal spaces and a period separating the
prefix from the extension. The list of file names MUST BE SORTED BY FILE
NAME in order for the fast file search to work.
The location index is the record number (line number) of the locator file,
whose default name is LIDX.DEF, and has the following layout:
columns 1-63: location of file
column 64: any character. MAKEFIDX puts in a period.
columns 65-66: carriage return line feed.
This file is all character data and is editable. Essentially, the
location index points to a record in the location file. E.g. if FIDX.DEF
has
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-16
RBBS-BAS.ZIP 2
HARPIE.ARC 3
and LIDX.DEF has
C:\DOWN1\
C:\DOWN2\
C:\UP\
Then RBBS-BAS.ZIP is located in directory C:\DOWN2 (2nd record) and
HARPIE.ARC is located in C:\UP (3rd record).
The location field should be a drive/path terminating with a "\" if any
path is given, and file must be filled with blanks through column 63 if the
path is shorter. You must put some character in column 64. Many editors
delete trailing blanks, so you should probably put in a non-blank. A
period is a suitable choice.
RBBS-PC will use a binary search on the first 12 characters in FIDX.DEF.
This binary search can be significantly speeded by provided "tabs" for this
file, indicating the record at which the first file is that begins with the
symbols "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ". This is like the "tabs"
you see on dictionaries, so you can directly turn to the B's, for example.
A tab file has the same prefix as the file name file, except that it adds a
"T". For "FIDX.DEF", the tab file would be "FIDXT.DEF". RBBS-PC will
automatically detect and use a tab file if available. The tab has 72
characters in it. Each 2 bytes represents a binary integer whose value is
the record number in FIDX.DEF where the first file occurs that begins with
the respective symbols above. Thus bytes 3-4 show where files begin with
"1" and bytes 69-70 where files begin with "Y".
Two utilities with source code are provided for setting up the fast file
searches. The source, for compiling under QB 4.5, is included.
MAKEFIDX will create both the file name list (FIDX.DEF) and the location
file (LIDX.DEF), from a list of directories (see MAKEFIDX.CFG) or a list of
file names, or both.
You must next sort FIDX.DEF by file name. A good shareware utility for
this is QSORT (QSORT FIDX.DEF /1:12).
MAKETABS will create a tab file (FIDXT.DEF) from the sorted file list
FIDX.DEF.
A sample batch file for recreating a fast file system is MAKEFFS.BAT. It
uses MAKEFIDX.EXE, QSORT.EXE, MAKETABS.EXE, and configuration file
MAKEFIDX.KG. You need only edit MAKEFIDX.KG to change the filespecs
(/FileSpec=) to match where your files are, and where to write the index
files.
Reconfiguring to Take Maximal Advantage of Fast File Searches
-------------------------------------------------------------
The fast file search is virtually instantaneous on an 8088 with a tab file
for 5000 file entries. The savings on wear and tear on the hard disk can
be very significant as well. And the time it takes to set up the fast
file search is only a few minutes. Most SysOps, therefore, will want to
implement fast file searching, whether or not they have a slow device like
a CD-ROM.
RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-17
RBBS-PC will first search through the drive/paths specified in config to be
available for downloading, as it always did. Files not found there will
then be searched using the fast file search system. The way the fast file
search works is that a file found in its list is looked for only in the
designated location. Nothing else is searched.
The optimal way to implement fast file searching is to reconfigure the
drive/paths available for downloading down to at most the upload directory,
and let the fast file search handle everything else. That way, files will
be searched first in the upload area, and those not found at first will
then be searched using the fast file search system. Note that every file in
the fast file search list is considered to be available for downloading
whether or not its drive/path is listed in the configuration program as a
downloadable area. Note that you can have separate fast file search
systems available for each sub-board. You can also use the fast file
search for common files and have a separate download area for the
sub-boards. Note that whenever you relocate files, you must re-create the
fast file search system. This is not hard since it takes little time and
can be automated.
Macros with the Fast File Search
--------------------------------
The location file for the FFS (LIDX.DEF) can have in it "M! <macro file>",
where "<macro file>" is the name of a macro, instead of a drive/path.
RBBS-PC will then execute the macro. Thus, you can have special
processing for classes of files, perhaps to
o advise that the upload is not wanted
o tell the caller on what other BBS the file can be found
RBBS-PC will put a "U", "D", or "V" in work variable 1 depending on whether
the file request is to upload, download, or view, so that you can customize
your macro for the situation. This if you want to display a message only
on an upload, you could have UNWANT.IMC with
0
{ON [1]
{==U
{*B
The file {C1{FI{C0 is {C2NOT WANTED{C0 here.
Please do not upload it.
{END
{END ON
RBBS-PC regards the file as not found when a macro is executed. However,
you can inside the macro use the macro command "LO" to set a location that
RBBS-PC will use to look for the file, the same as if the drive/path were
given in LIDX.DEF. Thus, you can use macros for files that really are
present. For example, if RBBS-EXE.ZIP is downloaded, the file is located
in D:\D1, and the entry RBBS-EXE.ZIP in FIDX.DEF is mapped to a record in
LIDX.DEF with the entry "M! C:\RBBS\DWNRBBS.IMC", then the following macro
displays a special message but still causes the file to be found:
0
{ON [1]
{==D
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-18
{*B
Congratulations. You are about to download the best BBS!
Call me voice at 703-978-4339 if you need any help.
{END
{LO D:\D1\
{END ON